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e information in our FileMaker databases is 
usually quite valuable and is often irreplaceable. The 
stored data represents significant investments of time 
and energy. So it is particularly disturbing that there is 
a chance that a FileMaker database can become dam¬ 
aged or even unusable. Safeguarding databases is thus 
an important aspect of using FileMaker wisely. 

FileMaker provides two built-in mechanisms for 
restoring damaged databases: AutoRepair and 
Recover. As the name implies, AutoRepair is run au¬ 
tomatically when necessary as the database is opened. 
On the other hand, Recover is a utility that is invoked 
manually by the user should the database require more 
extensive repairs. 

These facilities are designed to restore a damaged 
database so that it is again usable. The underlying phil¬ 
osophy of AutoRepair and Recover is to preserve as 
much of the database content as possible, while elimi¬ 
nating non-essential information that can easily be 
recreated. In this context, data content generically 


refers to records, layouts, scripts, and field definitions. 
Non-essential information refers to things like the cur¬ 
rent found set and sort order definitions. Rather than 
risk having the data inaccessible because of damage to 
a non-essential item, FileMaker deletes non-essentials 
in order to increase the probability that the database 
can be opened. 

A second important aspect of these facilities - and 
particularly of Recover - is that they do not guarantee 
that the file has been completely repaired. Exhaustively 
examining and repairing every aspect of a large data¬ 
base would be extremely time consuming, so both 
AutoRepair and Recover are designed to trade-off 
completeness for expediency. This trade-off is carefully 
made, with an emphasis on thoroughly checking the 
aspects of the database structure that are most likely to 
affect whether the database can be successfully opened. 
Therefore, users should take adequate precautions af¬ 
ter managing to get a damaged database open. “Ade¬ 
quate precautions” normally include immediately sav¬ 
ing a backup copy of the recovered database, and, 
depending on the severity of the problem, possibly im¬ 
porting the data into a clone of the original database. 
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An important safety measure is making 
regular and frequent backups. Many users 
operate their valuable, often irreplaceable 
databases without a safety net. Make those 
backups. Always assume that the worst can 
occur at any time, and never allow a signif¬ 
icant period of active database time go by 
without making a full backup. One good 
rule of thumb with a heavily-used database 
is that it should be backed up frequently 
enough so that you can add or update lost 
information without losing more than a 
day of work. 
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File Problems 

The most frequent cause of difficulty 
occurs when a FileMaker file is not closed 
“properly”. (Other causes of problems with 
FileMaker databases are related to media 
failure, where the file cannot be read by the 
file system.) A file is not closed properly 
when it is open and then: 

■ FileMaker freezes, forcing a manual 
restart of the computer; 

■ FileMaker runs into a problem and pre¬ 
sents a dialog that requires the user to quit 
the application (e.g., disk-read error or 
file-damaged error); 

■ Another application (or the Finder) 
crashes, causing FileMaker to crash; 

■ A manual restart is made for some other 
reason like a system hang-up; 

■ External power is interrupted, shutting 
down the computer abruptly. 

Note that, in all of these cases, not only 
is the active file damaged by being improp¬ 
erly closed, but so are all unlocked local 
files that may have been open at the same 
time. Files opened across the network from 
a still-powered remote machine are not 
damaged - the remote FileMaker applica¬ 
tion is still open. 


FileMaker Memory Management 

Many applications, including some 
databases, are “RAM-based”. RAM-based 
applications require that the entire docu¬ 
ment or database fit into memory at once. 
If an application with a RAM-based archi¬ 
tecture crashes, the most-recently-saved 
version is safe on disk. As a result, the doc¬ 
ument can be opened again intact, less the 
most recent changes before the crash that 
had not been saved. 

In contrast, FileMaker is a “disk-based” 
database. The document or database creat¬ 
ed by a disk-based application is not restrict¬ 
ed in size by the available RAM memory. 
Instead, small portions of the much larger 
document or database are brought into 
memory as needed. 

In the case of FileMaker, the informa¬ 
tion is brought into memory one disk 
block at a time. As memory becomes full 
(or when FileMaker is idle for several sec¬ 
onds), blocks in memory that have been 
changed are written back to the disk. A sin¬ 
gle simple operation, such as Replace, may 
alter many physical disk blocks that may be 
widely dispersed on the disk. In order for 
an operation to be successfully completed 
and for the stored database to be in a con¬ 
sistent state, all of the blocks related to any 
change mustht written back to disk. Obvi¬ 
ously, if even one of the blocks related to 
an operation is not written out to disk, the 
database on the disk is not left in a consis¬ 
tent state. This inconsistency may result in 
problems opening the database, or other 
difficulties while performing operations 
later. 

When FileMaker unexpectedly termi¬ 
nates, the extent of the damage to the data¬ 
base depends on the state of the database at 
the time of the crash. For example, if the 
file was a lookup table that was not 
changed while FileMaker was operating. 
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the file should be in a consistent state and 
AutoRepair should allow the file to be 
opened without further difficulty. Other 
examples of files that should be in a consis¬ 
tent state are files that have been idle long 
enough for all of the modified blocks to 
have been written to disk, or any file that is 
open and stable but is not the currently 
active database. On the other hand, if the 
database was being actively updated at the 
time of the shutdown, as could be the case 
in a mass deletion or update, it may re¬ 
quire the more serious repair measures 
provided by Recover. 

Typical Error Messages 

Depending on the state of the database 
when FileMaker unexpectedly terminates, 
the warning that appears when the data¬ 
base is reopened may be one of a variety of 
messages. Figure 1 shows a message that 
typically appears when opening a stable file 
after an unexpected shutdown. (The first is 
from Pro 1.0 and the second from Pro 2.0.) 

In the case indicated in Figure 1, File¬ 
Maker was able to open the database suc¬ 
cessfully but has detected that it was not 
closed properly the last time it was used. 
AutoRepair is automatically invoked to 
validate the database. Consistent with File¬ 
Maker’s philosophy of eliminating what 
can easily be recreated (to avoid possible 
problems), any found-set and sort-order 
definitions are discarded as the database is 
repaired. In addition, FileMaker checks for 
records that may have been partially up¬ 
dated and triggers calculations in those 
records. In versions prior to Pro 2.0, it also 
re-counts the records to verify the consis¬ 
tency of the internal record list. 

Keep in mind that any operations in 
progress prior to the failure (such as 
Replace or Delete) will not be completed 
by AutoRepair. As a general rule, after a 


This file mas not closed properly. FileMaker 
is performing minor repairs. 


This file mas not closed properly. FileMaker 
is nom performing a consistency check. 


repaired or recovered database has been 
successfully opened, the file should be 
checked by the user for consistent content. 

This is especially true if there was an active 
operation under way at the time of the 
shutdown. 

A similar message maybe seen in other 
cases where the database was shut down 
improperly - the dialog in Figure 2, for in¬ 
stance. In this case, FileMaker was able to 
open the database successfully but has again 
detected that it was not closed properly the 
last time it was used. Furthermore, File¬ 
Maker has detected that free blocks 
associated with the database were not re¬ 
leased the last time it was closed. This con¬ 
dition may cause the file to be larger than is 
necessary because these particular empty 
blocks cannot be reused. The error alert 
suggests running Recover if there are prob¬ 
lems, and suggests a method for compress¬ 
ing the database if everything works prop¬ 
erly, Generally, saving a compressed copy 
after the file is open is sufficient to com¬ 
press empty space out of the database. 

Sometimes the problems with a database 

are more severe and AutoRepair does not _. _ 

Figure 2 



“Database” mas not closed properly. 

• If you haue problems mith this file, use the 
Recouer command. 

• If this file morks properly, Saue a Copy that 
is a clone, then use the Import command to 
make a smaller file. 


( OK ) 
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Sorry, this file is damaged. Click Resume to 

1, j continue using this file, or click Quit to euit 
FileMaker. Consult the FileMaker manual for 
information on Recouery. 

[ Quit J|[ Resume ]| 



Sorry, FileMaker is unable to read the disk. 

Click Retry to try again, or click Quit and copy 
this file to another disk. (Error -127 at 115) 

( Quit )|( Retry ]| 



Sorry, this fiie is badly damaged. Please use 
the Recouer command. 

(( Quit )) 



“Oatabase” mas not created by FileMaker or is 
seuerely damaged and cannot be opened. 

(-2!<_l 


Figure 3 


work. In these cases, a more extensive pro¬ 
cess must be performed to resuscitate dam¬ 
aged files. Recover is provided as a separate 
feature that performs this operation. Re¬ 
cover creates a new empty database and 
copies the information from the old file 
block by block before validating various 
aspects of the database structure. 

Recover may be necessary if one of the 
alerts shown in Figure 3 appears while File¬ 
Maker is in operation. While the first alert 
indicates that a problem was encountered 
and the file is damaged, in fact the file may 
not necessarily be damaged. This alert is re¬ 
lated to a variety of conditions that occur 
throughout FileMaker. It may be the result 
of a programming error, information miss¬ 
ing from the database, or an internal pro¬ 
gram validation failure. Clicking Resume 
(usually multiple times) may bypass the 


error, but most often the situation can only 
be resolved by quitting the application. 

Quitting in this manner initiates pro¬ 
gram code that makes a last-ditch attempt 
to write all of the modified data blocks 
from memory back to disk. It then shuts 
down the file. However, the file is not 
properly closed and opening it subsequent¬ 
ly will cause AutoRepair to be executed. If 
the database opens successfully, and the 
error does not recur. Recover is unneces¬ 
sary. On the other hand, if the condition 
recurs. Recover should be used to correct 
the problem. Other errors of this type in¬ 
clude errors reading from and writing to 
the disk - known as input/output or I/O 
errors. Unfortunately (unless the database 
is on a floppy disk that has been ejected) an 
I/O error message indicates a serious prob¬ 
lem that will require a Recover operation. 

There are other more serious problems 
that prevent the file from being opened. 
Generally these errors are encountered 
when attempting to open the database. 
Usually they are the result of problems in 
the structure of the database. Structural 
problems include references to invalid 
block numbers or invalid information in 
the signature blocks of the database that 
identify a file as a FileMaker database. 
Depending on the severity of the problem, 
FileMaker may be unable even to Recover 
the database and reverting to a backup will 
be necessary. 

Recover Step by Step 

To activate Recover, launch FileMaker 
and select the Recover function from the 
File menu. FileMaker asks you to select the 
file to be recovered and to specify a name 
for the new database that will be created in 
the process of recovery (it must be a differ¬ 
ent name than the file being recovered). 
The status dialog shown in Figure 4 then 
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appears and reports the progress of the 
Recover operation. 



The first step in Recover is to open the 
damaged database and create a new empty 
database to hold data blocks that are about 
to be copied from the damaged file. 


Copying saluaged information to new file. 


Next FileMaker resets the logical End of 
File (EOF) in the damaged database to be 
equal to the physical EOF and starts copy¬ 
ing each block of the damaged database 
over to the new target file. As each block is 
copied, it is examined to validate its inter¬ 
nal structure. If any problem is found, the 
block is repaired. 


The name of this step is a bit of a mis¬ 
nomer. Rather than rebuilding the status 
information, FileMaker actually reverts the 
database to a default state similar to a 
brand new database. Once again, this is 
consistent with the philosophy of remov¬ 
ing what can easily be recreated in order to 
concentrate on capturing as much of the 
old content as possible. The items that are 
removed or reverted include: 

Record count. Summaries, Sub-sum¬ 
mary sort order. Record sort order. Cus¬ 
tom sort order, Found records list. Import 
order. Export order. Calculation trigger 
table. Find patterns. Sort specification. 


Checking the records for damage. 


Next, FileMaker validates each record 
in the database. This process involves 
fetching the records and checking to make 


sure that each 
has valid 
header infor¬ 
mation. Also, 
each field 
within the 
record is 
checked for a 
valid key and 
valid (non¬ 
zero) length. 

If any invalid Figure 4 

fields or records are discovered in this pro¬ 
cess, they are removed from the database. 

As each field is validated, it is checked 
against a master list of existing fields. If a 
field is encountered that does not already 
exist in the master list, the key is added to 
the list so that a temporary field can be cre¬ 
ated automatically later. Again, this is con¬ 
sistent with FileMaker’s philosophy of pre¬ 
serving as much of the information as 
possible. It is easy for the user to delete un¬ 
wanted fields after the database is recovered 
- much easier than attempting to recreate 
lost information. 

Furthermore, in FileMaker Pro 2.0, any 
data in repetitions of repeating fields that 
are beyond the maximum value specified in 
field definitions are deleted. Deleting these 
unseen repetitions will cause any summa¬ 
ries or calculations that include the repeat- ‘ 
ing fields to be calculated correctly because 
they no longer involve the “hidden” data. 

When FileMaker finishes checking the 
records, it writes the maximum record 
count and the maximum record key back 
into the database. 


Checking the layouts. 


In this phase of recovery, FileMaker val¬ 
idates each layout in the database. First, the 
current defaults (i.e., current font, size, 


Creating the neui empty file. 


ICopying saluaged information to neui file. 


Rebuilding the status information. 
Checking the records for damage. 
Checking the layouts. 

Rebuilding lost field definitions. 
Rebuilding inden. 

Freeing unused space in file. 

Kbytes copied: 

20 
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Locked Databases 

In FileMaker Pro 2.0, databases can now be locked so they be¬ 
come read-only files. Read-only databases are particularly 
useful for lookup files that change infrequently or never. 
Making a database read-only protects the contents from 
change, and if FileMaker terminates unexpectedly, the data¬ 
base will not need to be repaired or recovered. To lock a data¬ 
base from the Finder, select the file and choose Get Info from 
the File menu. Simply click the Locked checkbox in the info 
dialog to lock the database. 


style, etc.) are replaced with defaults that 
match those of a newly created database. In 
addition, lists used by FileMaker to quickly 
access the layout names and information 
about custom layout order are deleted. 

Each layout is then examined for con¬ 
sistency. Every layout must have a name 
(or it is given a default name), parts (at 
least one) with valid options and valid size, 
and a valid object list. The object list is a 
structure that contains a reference to each 
object (i.e., field, rectangle, line, text, etc.) 
on the layout. Each object referenced in the 
object list is fetched to make sure it is 
present and that it is a valid object type. 
Any objects that cannot be examined or are 
not of a valid type are deleted from the lay¬ 
out. If any invalid parts are encountered, 
they are also deleted. If no parts are left af¬ 
ter this process, a default part is added to 
the layout to make it accessible. 


Rebuilding lost field definitions. 


Next, FileMaker validates all field defi¬ 
nitions and scripts. First, lists used by File¬ 
Maker to quickly access the field names 
and information about the custom field 
order are deleted. While validating field 
definitions, any fields without matching 
definitions (discovered while checking the 
records) will have new field definitions au¬ 


tomatically created. Each automatically- 
generated field is named “Recovered Field 
n”, where “n” is a number starting at 1 and 
incrementing with each field, “n” is auto¬ 
matically generated during recovery. File¬ 
Maker also fetches each field definition 
from the database and verifies that it has a 
valid field name and valid field type. If the 
field type is missing or invalid FileMaker 
makes the field a text field (the most flexi¬ 
ble type), so any data can be retrieved from 
the field. In the case of calculations and 
summaries, the formula is fetched and vali¬ 
dated. If any of the formulas are invalid or 
cannot be found, a default empty formula 
is created for the field. Finally, FileMaker 
writes the count of the number of fields 
into the file. 

When it has finished processing field 
definitions, FileMaker validates the scripts 
in the database. As was done for layouts 
and field definitions, FileMaker starts by 
deleting the custom order information for 
scripts. Every script is then checked to 
make sure it has a valid name, valid status 
information and valid options. If a prob¬ 
lem is detected with any of these important 
script components, the script is deleted. 


Rebuilding indeu. 


After checking each record and rebuild¬ 
ing the field definitions, FileMaker is final¬ 
ly ready to reconstruct the inverted list or 
index. The index is used to assist FileMaker 
in locating data quickly. After completely 
deleting the existing index, FileMaker 
fetches each record, and, based on the data 
in the record, reconstructs the index from 
scratch. This step is necessary to maintain 
consistency in the database. If the index 
were not rebuilt, it would be possible for 
FileMaker Find requests to return records 
that did not match the specified request. 
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Freeing unused space in the file. 


Finally, FileMaker frees unused space in 
the file. All of the disk blocks that may be 
unused after recovery are coalesced to the 
end of the file and removed. 

Recovery Results 

When recovery is completed, a status 
dialog is displayed showing what was done 
to the database during recovery. The dialog 
(Figure 5) shows: 

■ the number of bytes copied from the 
damaged database into the new database; 

■ the number of records that had to be 
skipped (deleted) from the recovered data¬ 
base; 

■ the number of field values that had to be 
skipped (deleted) from the database; 

■ the number of field definitions that had 
to be recreated. 

If any of the values shown, other than 
the number of bytes copied, is greater than 
zero, you should carefully check the file for 
consistent content. For example, if field 
definitions are recreated by Recover, you 
can create a new layout with the “recov¬ 
ered” fields and search for records where 
the field values are not empty. Based on the 
contents of each field, you may decide to 
delete the field again. 

In many cases, a successfully recovered 
database may be larger than the original 
database. This is normal and is caused by 
new disk blocks being allocated as the data¬ 
base is recovered. For example, rebuilding 
the index field by field and record by 
record can cause data distribution that is 
different (and possibly larger) than the 
original file. 

A newly recovered database will also 
take longer to open than a database that 
was closed properly the last time it was 
used. This only happens the first time a 


Recouery is complete. During recouery: 

91 IK bytes mere saluaged. 

0 luhole records mere skipped. 

0 field ualues mere skipped. 

0 lost field definitions mere rebuilt. 

If you haue further problems mith this file, call Claris 
Technical Support. 


recovered database is opened, and is the 
result of rebuilding various internal struc¬ 
tures that were deleted during recovery. 


Figure 5 


Stabilizing Your Database System 

There are a number of things that can 
be done that will have a direct impact on 
the stability of your system and on the reli¬ 
ability of your databases. The following 
general guidelines will help protect your 
investment in your data. 

■ Make frequent backups. This cannot 
be stressed enough. Many users do not 
have adequate protection against data loss. 
In many cases, they do not have their data¬ 
bases backed up at all. A backup not only 
prevents loss of data if a database cannot 
be successfully recovered, it can actually be 
an excellent alternative to Recover. Instead 
of recovering a damaged file, it often pays 
to restore a backup copy of the database, 
even if it needs some work to bring it up to 
date. For a large database the time required 
to perform a full Recover will generally be 
much longer than the time required to re¬ 
store and update the backup. 

■ Save compressed copies of the data¬ 
base periodically. Saving a compressed 
copy rewrites the entire database, fitting as 
much data into each block as possible. This 
procedure will not only reclaim dead space 
in the file, but will also, as a consequence, 
rebuild the file’s structure. Backing up 


Tip 


Make 

Reguair 

& 

Frequent 

Backups! 
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Memory Preferences 

In FileMaker Pro 2.0 memory preferences were added to aid 
users working on portables where battery life is a consideration. 
In previous versions of FileMaker, the code that automatically 
flushes the file cache to disk would repeatedly start up the disk 
during idle time, prematurely running down the batteries. In 
FileMaker Pro 2.0, users are allowed to control the interval 
between automatic writes to disk. When setting the time inter¬ 
val for automatic writes, keep in mind that increasing the delay 
also increases the exposure to database damage should the 
application terminate unexpectedly. 


Tip 


Keep in mind that 
saving a compressed 
copy may take a long 
time for a large 
database, so you 
might perform the 
compression 
overnight. 


compressed copies is one approach, and 
saves backup space as well. 

■ Save a clone of the file periodically. 
Having a clone of the most recent database 
structure on hand can be useful if you have 
to recover your database. For one thing, it 
preserves various customized aspects of the 
file such as custom script, field and layout 
arrangements. Further, if any of the scripts 
or layouts in a database are damaged and 
are deleted by Recover, the clone can be 
used to reconstruct the lost scripts or lay¬ 
outs. A clone is also useful if you need to 
import data from a recovered database. 

■ Stay well clear of the 32 MByte file 
size limit. If you hit the limit you may be 
unable to Recover the database. In a large 
file be particularly careful when perform¬ 
ing global operations - such as Replace, 
Import, Delete, or adding new equations - 
that might expand the database beyond 32 
MBytes. It seems like deleting data should 
make the database smaller but the process 
of shifting data blocks around and altering 
the internal structure may actually cause 
more disk blocks to be used than were in 
the original file. Although saving a com¬ 
pressed copy will reclaim this unused 
space, if you go over the 32 MByte limit 
while performing the deletion, you could 


do irreparable damage to the database. 

■ Remove as many suspicious system 
extensions as you can get along without, at 
least until you are convinced they are not 
having deleterious effects. There are vari¬ 
ous third party products available that al¬ 
low you to turn selected extensions on and 
off so you don’t have to physically remove 
them from your system. 

■ Make sure there are no viruses in 
your system and data files. Although File¬ 
Maker Pro does internal checks on the ap¬ 
plication far viruses at launch time, data 
files can still be infected. Therefore, use a 
current copy of a virus detection program 
to check your system. Using the most re¬ 
cent copy of virus detection software is im¬ 
portant because these programs are peri¬ 
odically updated to detect new virus 
strains. 

■ If you experience frequent power 
outages in your location, think about get¬ 
ting an uninterruptible power supply 
(UPS). A UPS will quickly pay for itself in 
terms of work hours saved by not having to 
repair or recover files that were improperly 
closed due to a power failure. 

■ Obtain the most recent version of 
FileMaker Pro from Claris. Often there are 
corrections available for problems that 
have been discovered since your version 
was shipped. These fixes may prevent 
problems that might otherwise require you 
to recover your database. 

■ If you have a file that needs frequent 
recovery, it may make sense to rebuild the 
database. As mentioned earlier. Recover is 
not guaranteed to fix every problem. The 
difficulty you are experiencing might be 
the result of damage in the database that 
Recover does not address. The safest ap¬ 
proach is to rebuild the database from 
scratch, exporting your data to a text file 
before importing it into the new database. 
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Obviously, this procedure can be quite 
time consuming, especially with a large 
database and/or a complex design, and 
should only be done if the database has 
severe or recurring problems. 

A less rigorous approach is to use a 
clone of the original database as the basis 
of the new database. Keep in mind that the 
problem may exist in the clone and using it 
for the basis of the new database may not 
produce satisfactory results. 

Another timesaving technique is to 
directly import the data from the original 


recovered file into the clone rather than 
going through a text-file intermediary. 

Once again, this approach may also intro¬ 
duce problems in the “sanitized” database. 
In particular, style runs (the structure that 
describes the style changes applied to data 
in Browse mode) will be copied into the 
new database along with the data. Style 
runs can sometimes cause problems with 
particular records, causing the application 
to freeze when displaying that record. 

-At* 


Notes on Fixing Files 


By Joe Kroeger 

Overall, Repair and Recover are pow¬ 
erful and productive tools and constitute 
important FileMaker features. The lead 
article in this issue explains many of their 
operating details. I learned several new and 
illuminating things that will modify my 
operating procedures. Note that compress¬ 
ing a file regenerates part of its structure as 
well as making it smaller, so I’ll be doing 
more compressing. And locking lookup 
files is a great new feature. 

Repair and Recover are valuable, and 
we should gives thanks that we have them. 
But each extracts payments in return. Ad¬ 
ditional work by the user may be necessary 
on occasion. And both take time to exe¬ 
cute. Repair times are usually quite modest 
- a matter of a few minutes. Of course, 
large files can take longer. Example: a file 
with 24,000 records that uses about 22 
MBytes takes about 16 minutes for a sim¬ 
ple Repair on a stock Mac Ilci. 

Recover is a much more complex pro¬ 
cess and takes longer than Repair. For ex¬ 


ample, a 1.3 MByte file with 2600 records, 
29 fields including 5 calculations, and two 
layouts, takes about 19 minutes to Recover 
on a Mac IIx. Another example at the other 
end of the scale: a 24 MByte file with about 
23,000 records, 75 fields including 25 equa¬ 
tions, and nine layouts, takes more than 
seven hours to recover on a 25 MHz 68040 
Radius Rocket. For large files especially, it 
makes sense to work hard to minimize 
potential problems and to keep backups 
current. Pro 2.0 does much faster repairs. 

It is easy to put up with short Repair 
and Recover times - after all, we are get¬ 
ting our lost data back! A little planning 
can minimize the impact of long recovers. 
Recovering overnight often works well. If 
you have the option to move the file to be 
recovered to a faster machine, that will 
help. Availability of a recent backup may 
obviate use of Recover at all. 

I once inadvertently bumped into the 
FileMaker 32 MByte file size limit and I am 
here, tattered and torn, to suggest that you 
heed the admonition to stay clear of the 
limit. In large systems this may mean 
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Preview 


Putting files on a diet 
is the subject of an 
upcoming article. 


Anti-Virus 


I use Disinfectant - it 
is free, easy to use, 
and competent. The 
current version is 2.9. 
It would be a shame 
to have a system 
crash or a FileMaker 
crash due to a virus 
that could have been 
detected. 


Page 10 • Issue 47 


rethinking file organization or locating lit¬ 
tle-used records that can be deleted or 
identifying equations that can be removed. 

I make regular and frequent backups. (I 
learned my lesson a few years ago when I 
lost some valuable files.) But I also talk to 
many users who are surprisingly casual 
about backups. In a FileMaker environ¬ 
ment it is doubly important to maintain a 
strict backup discipline: a hard disk may 
get scrambled and FileMaker files may get 
damaged. 

Your backup strategy should be con¬ 
sciously designed to take into account your 
own context. How often should you back¬ 
up? How many independent sets of back¬ 
ups should you have? How many off-site 
backups? How many grandfather backups? 
In addition to regular and frequent back¬ 
ups, it is important to maintain more than 
one backup. 

I have been using a Teac cartridge tape 
for backups for several years - it is faster 
than other tapes, does not require initial¬ 
ization of new tapes, and is relatively inex¬ 
pensive. But I expect soon to invest in a 
128 MByte magneto-optical drive that will 
be used for backups as well as other tasks. 

It will be a little more expensive, but a lot 
faster. 

I use Retrospect to drive the tape back¬ 
ups. Retrospect is popular and seems to be 
reliable, but I think it has an awkward user 
interface, an inconsistent nomenclature, 
and is difficult to use in some circumstanc¬ 
es. If you can work with a full backup plus 
on-going incremental backups and if you 
have only one hard disk, Retrospect is 
manageable. Unfortunately, I have two 
(and sometimes three) hard disks going 
and I need to back up about 15 large files, 
most of which are edited every day. Thus, 
incremental backups are nearly as large as 
full backups so I prefer to execute a full 


backup every time and this is a pain to ac¬ 
complish. 

I do a full backup about every other 
day. I have six sets of backup tapes and I 
date each backup session. The oldest tape 
set is selected for use with the current 
backup. In addition, I have a seventh set of 
tapes that is kept off-site and is renewed 
about every two weeks. Further, each quar¬ 
ter I make a full backup to a new set of 
tapes to use as an off-site grandfather back¬ 
up that is not renewed for about two years. 

For a small system (Mac Plus and mod¬ 
est hard drive) I backup to diskettes. Disk- 
Fit Pro has been improved significantly 
over the older versions, allowing more ver¬ 
satile file selection, and works well with 
diskettes. DiskFit builds a new full-backup 
each session, and does so by just replacing 
the files that have changed. 

In addition to regular backups of data, 
a clone of a database is a valuable reference 
for post-recovery work. A printed version 
of the field definitions is also nice to have 
on file. 

A custom field definition sequence that 
is deleted by Recover can be a (minor) 
problem if you rely on field groupings to 
help locate fields for building equations or 
lookups. 

A deleted custom script sequence can 
be a bigger problem - Warning: when the 
scripts revert back to their as-entered se¬ 
quence, the keyboard command shortcuts 
are automatically reassigned. Thus if you 
depend on keyboard shortcuts as part of a 
macro, for example, or even just in a writ¬ 
ten or mental procedure, it will be vital to 
either rearrange the scripts into the se¬ 
quence desired or revise the procedures 
that use the keyboard shortcuts. 
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Augmenting Value List Functionality 


By Matthew Bowe 

Claris Tech Support 

Value Lists can be effective tools for 
simplifying data entry. The article “Making 
Use of FileMaker Value Lists” in the previ¬ 
ous issue of The FileMaker Report explains 
their uses and many of their characteristics. 

Radio buttons and pop-up menus in 
particular have valuable built-in con¬ 
straints. The user efficiently selects values 
to enter the desired information in the 
field. Changes in the selection are made by 
choosing a different list value but the user 
cannot, with simple mouse clicks, select 
more than one value at a time nor deselect 
a previously selected value allowing the 
field to return to empty. 

In situations where mutually-exclusive 
lists of data are being used, radio buttons 
and pop-up menus, with their concomi¬ 
tant restrictions, are effective. However, 
there are times when overriding these con¬ 
straints might be desirable. Judicious use of 
the shift key in the following (undocu¬ 
mented) features extends the power and 
flexibility of radio buttons and pop-up 
menus to include these abilities. 

Selecting Multiple Values 

Selecting multiple values from pop-up 
lists or radio buttons is made possible by 
first selecting one value in the regular way 
and then holding down the shift key while 
selecting a second (and third, and fourth. 


.. .etc) value(s). All previously selected val¬ 
ues will remain, and the new value(s) will 
be indicated as being selected. (A Find for 
any of the multiply-selected values in a 
record will yield the record as part of the 
found set.) 

If the shift key is released and another 
value is chosen, all previously selected val¬ 
ues will be deselected and the newly select¬ 
ed value will remain selected. 

Deselecting Values 

After selecting a value for the first time 
in a field formatted with radio buttons or 
as a pop-up menu, there seems to be no 
apparent way to deselect this value so that 
the field has no value chosen. Using a space 
as a value in the list (See “Using Radio But¬ 
tons in Find Screens” in the previous issue) 
is one option for solving this problem. 

However, deselecting the value can be 
accomplished by holding down the shift 
key and choosing the currently selected 
value. The selected value will deselect and 
the field will now be empty. 

Radio buttons and pop-up menus are 
purposely restricted and, in most instances, 
serve their proper purpose. The techniques 
described above allow the user to override 
these restrictions thus gaining even more 
control over data entry operations. 


Note 


Our thanks to the 
several subscribers 
who, after the last 
issue, called our 
attention to one or 
the other of the 
techniques described 
here. - Ed 
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Equation du Jour 


Disappearing Data: Displaying Calculated Blanks 


By Glenn Nunez 


Occasionally, when working with a 
calculated field in FileMaker, the result of a 
calculation needs to be displayed as a 
blank. This is a simple task if the field in 
question is a text field - an equation that 
results in nothing (or in a soft space) works 
just fine. When the field has a numeric 
result, however, a different approach must 
be used. A calculated numeric field with a 
blank result will display as a zero, not a 
blank. 

Claris Tech Support recognizes this sit¬ 
uation and has written a couple of Techni¬ 
cal Briefs in response. They state that File¬ 
Maker cannot display a blank in a 
calculated number field and offer solutions 
involving the creation of a corresponding 
text field. A value in this text field may 
then be shown as a blank. A problem arises 
in that a text field does not have the num¬ 
ber formatting capabilities of a numeric 
field, as the Brief makes clear. 

It turns out that there is also another 
solution. FileMaker can display a blank in a 
calculated number field after all. 

Although it was clearly created for oth¬ 
er purposes, it turns out that the TextTo- 
Num function fits the bill here perfectly. 
The expression TextToNum ("") - with 
nothing between the pair of quotes - yields 
the desired blank. When used in further 
calculations the value equates to zero, 
which is usually what is intended. Because 
the field is a numeric field, non-blank val¬ 
ues can still retain whatever number for¬ 
matting options are appropriate. 


Grid Display 

This discovery has several applications 
- some cosmetic, some convenient, and 
some down-right useful. A recent project 
involved comparing two sets of keyboard 
characters, one set named TestCharacter 
and the other named Symbol. The results 
of the comparisons are displayed in a grid 
composed of three values: 

(1) When TestCharacter is greater than 
Symbol a “1” is needed both for the grid 
display and for an additional numerical 
calculation. 

(2) When TestCharacter is less than Sym¬ 
bol a “0” (zero) is needed. 

(3) When TestCharacter equals Symbol, a 
third value - clearly distinguishable from 
“1” or “0” - was desired for display pur¬ 
poses while a “0” was again required for 
the numerical calculation. 

The TextToNum function solved the 
problem beautifully by calculating a blank 
for the third condition, thus providing the 
clearly distinguishable value: 

GridDisplay= {number result} 

If (TestCharacter > Symbol, 1, 

If (TestCharacter < Symbol, 0, 

TextToNum (""))) 

TextToNum to the rescue! 

As luck would have it, this trick works 
not only with numbers but also with dates 
and times. The functions TextToDate ("") 
and TextToTime ("") - again, with noth¬ 
ing between the pairs of quotes - yield 
blanks in calculated date and time fields, 
thus allowing non-blank date and time 
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Tape Number Title Rental Number 

5202 Presu med Innocent _^ 

Date Rented Date Due Time & Date Returned 

Sat, Apr 11,1992 Sun, Apr 12 _ 


□ □ 


Figure 1 


Tape Number 

5202 

Title Rental Number 

Presumed Iimocent 20 

Date Rented 

Date Due 

Time & Date Returned 

Overdue 

Sat, April, 1992 

Sun, Apr 12 

2:38 PM-Tue, Aprl4 

2 Days 

Late Fee 

Assess $5.40 

Assess $1.00 

Total 

Override 

Late Fee? 

Rewind Fee? 

Fees 




$6.40 


Figure 2 


not be critical to the file’s overall perfor¬ 
mance, it is slightly more elegant. And isn’t 
that part of what FileMaker is all about? 

Glenn Nunez is a Senior Consultant at 
Watertechnics, a small business consulting 
firm. He can be reached through the office at 
408-761-3987 or directly at 510-452-2116. 


values to be properly formatted when 
necessary. 

Data Entry Prompts 

This may be desirable, for instance, on 
data entry screens where entering a value 
in a field triggers prompts for more infor¬ 
mation. Figure 1 shows part of a data entry 
screen used at a video rental store to deter¬ 
mine fees which may be due when movies 
are returned. 

When the screen is first opened, the 
lower portion is empty. DateReturned is 
an operator-entered value. TimeReturned 
is a calculated value: 

TimeReturned = {time result} 

If (DateReturned = "TextToTime (""), 
ModificationTime) 

When today’s date is entered in Date- 
Returned, the value in TimeReturned 
appears on the screen, as do several 
prompts and calculations which depend on 
the values in DateReturned and Time- 
Returned. See Figure 2. 

Displaying the calculated “layout text” 
on the bottom line is a straightforward 
process using text fields. Without the Text¬ 
ToTime and TextToNum functions, how¬ 
ever, the time and number fields Time- 
Returned (2:38 PM), LateFee ($5.40), 
RewindFee ($1.00), andTotalFees ($6.40) 
would show as unwanted zeros in Figure 1. 

If these same values were instead calcu¬ 
lated in text fields, they would correctly 
show as the desired blanks in Figure 1, but 
would be shown unformatted (14:38:00, 
5.4, 1, 6.4) in Figure 2. The expressions 
TextToTime ("") and TextToNum ("") 
allow these values to be displayed exactly as 
desired in both instances. While this may 




About FileMaker Pro 2.0 

There are apparently a few bugs and glitches in 
the newly-released FileMaker. Rumors have it 
that Claris will issue a new version FileMaker Pro 
2.0 v2 very soon. Wait for it if you can. Mean¬ 
while, it wouldn’t hurt to Compress or Com- 
press-and-Recover old files before converting 
them to 2.0. -Ed 
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Latest-Record Lookups in FileMaker 


By Don Cohen 

Lexington, MA 

Where I work we use two related File¬ 
Maker Pro files that contain information 
about people who do contract work for the 
company. One, the Service Vendors file, 
has a record for each person we hire and 
contains essential information such as 
name, address, phone number, social secu¬ 
rity number, work experience, particular 
skills, current rate, and so forth. 

The other, the Contracts file, has a 
record for each contract with a service ven¬ 
dor. Included on each record are the name 
and social security number of the service 
provider as well as other information 
about the particular contract such as be¬ 
ginning and end dates, service provided, 
rate charged, and total cost. 

Over a period of time, a vendor is often 
likely to have had several contracts with the 
company. We put this contract informa¬ 
tion in separate records in the Contracts 
file rather than in repeating fields in the 
Service Vendor records so that we can eas¬ 
ily sort, summarize, and extract informa¬ 
tion about individual contracts - hard to 
do if several contracts are lumped together 
in repeating fields. 

We decided that it would be useful to 
draw information about each vendor’s 
most recent contract from the Contracts 
file into the Service Vendors file. This 
would allow us to see at a glance when the 
vendor last worked for us, what service was 
provided, and what rate was charged. The 
challenge was to make sure FileMaker 
would always look up information for each 


individual from the record having the latest 
Contract End date. 

Because they are unique identifiers, it 
clearly made sense to use the social security 
number as the key that would match ser¬ 
vice vendors in one file to their contracts in 
the other. My first thought was simply to 
sort the Contract file by vendor and in de¬ 
scending order by End Date. 

Since a lookup copies information from 
the first match it finds, I thought FileMak¬ 
er would “see” the record of each person’s 
latest contract first and copy the informa¬ 
tion we wanted into the Service Vendor 
file. Unfortunately, the lookup feature ig¬ 
nores sorts and always looks at records in 
their order of creation. 

Of course it would be possible to sort 
the records, pour them into a clone of the 
contract file, and make that clone the look¬ 
up file. But that seems a tedious and inele¬ 
gant procedure to be followed every time 
an update is needed. 

The challenge is to get FileMaker to do 
the work instead - elegance is essential. Us¬ 
ing the “Maximum” option in a summary 
field in combination with a summary cal¬ 
culation in the Contracts file, I was able to 
solve the problem. 

First I created a summary field, called 
Maxdate, that gives the maximum value 
(i.e., the most recent date) in End Date. 
This field contains the maximum value for 
the whole file or for a group of found 
records, so it does not give the latest date 
for each vendor. A summary calculation is 
needed to extract latest end dates by ven¬ 
dor from Maxdate. This calculation, called 
Checkdate, is: 
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Checkdate = Summary (Maxdate, SSN) 

SSN (the field containing social security 
numbers) is the ‘break’ field required for 
this calculation. When the Contracts file is 
sorted by SSN, Checkdate will give the 
most recent end date (the Maxdate) for 
each group of records with the same social 
security number - that is, for each service 
vendor. 

It is now a simple matter to create a cal¬ 
culation field in the Contracts file that will 
serve as a lookup key for the Service Ven¬ 
dor file: 

Key = If (Checkdate = End Date, SSN, "") 

For each vendor, the social security 
number will be copied into the key field 
only in the record where the Checkdate - 
the most recent end date in all the records 
for that vendor - matches the End Date on 
that record. In all other cases, the key field 
will remain blank. 

Note that the calculation result for Key 
should be text, not numeric. Treating 
social security numbers as numbers creates 
problems, such as the loss of initial zeros. 
For this same reason SSN is a text field, not 
a number field. 

The lookup fields in the Service Ven¬ 
dor file - Rate, End Date, and Service Pro¬ 
vided - look for matches between the Ser¬ 
vice Vendor file SSN field and the Key 
field in the Contracts file. It only finds a 
match on records with each vendor’s most 
recent End Date and therefore copies in¬ 
formation only from those records. 

The process of updating the Service 
Vendor file to reflect new entries in the 
Contracts file is quite simple. First, the 
Contracts file must be sorted by SSN. I 
created a script in the Contracts file that 


finds all records and sorts by SSN. Then it 
is only necessary to click into the SSN field 
on any record in the Service Vendor file 
and choose Relookup from the Edit menu. 

Elegance is not just nice - it also is one 
way to keep score: FileMaker can do most 
anything. 


Editor's Note 

Don’s technique is both interesting and powerful. At a more 
general level, this is an example of an “Active Lookup” file. 
Most lookups are simply passive files containing static data. 
But here the lookup file (a) regularly has new information 
entered and (b) is able to adaptively reorganize itself to ad¬ 
just the lookups that will happen. Active Lookups have 
many interesting uses. 

FileMaker Pro 2.0 will probably make Don’s solution even 
easier to implement. It may be possible to create a script in 
the Service Vendor file that, when executed, will automati¬ 
cally go to Contracts, execute the Sort, return to Service 
Vendor and execute the Relookup. This ability is going to 
make Active Lookups even easier to use. 
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About FileMaker 

The latest version of FileMaker is FUeMaker Pro 2.0 vl with 
a release date of October, 1992. Previous versions of File¬ 
Maker include: 

Version First Release Date 


FileMaker 1.0 
FileMaker Plus 
FileMaker 4 
FileMaker II 
FileMaker Pro 1.0 vl 
FileMaker Pro 1.0 v2 
FileMaker Pro 1.0 v3 


May 1985 
August 1986 
July 1988 
October 1988 
October 1990 
April 1991 
March 1992 
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